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ABSTRACT 


In a stand-alone database management system (DBMS), one of the key compo- 
nents is the real-time monitor (RTM) which handles database accesses and responses at 


run time. .In the Multimodel, Multilingual and Multibackend Database Management Sys- 


tem (M°>DBMS) developed at the Laboratory for Database System Research in the Naval 
Postgraduate School, there is also the need of a RTM in order to link a specific Data 
Model and Data Language Interface to the Kernel DBMS. The problem addressed by this 


thesis is to design and implement a RTM for the Object-Oriented Interface in M°DBMS. 

In this interface each object-oriented (OQ) query is converted into the equivalent 
Attribute-Based Data Language (ABDL) queries. However, due to the complexity of the 
OO operations there is no way to produce these ABDL queries in complete and execut- 
able forms. Much of the information needed for the completion and execution of the 
ABDL queries is provided by the previous ABDL queries. The approach was to develope 
a RTM which oversees the execution of previous ABDL queries, receives the intermedi- 
ate results from these queries, and completes the subsequent ABDL queries for execution 
in the Kernel. 

The result of this thesis is a RTM which executes the OO query as directed by the 
compiler of object-oriented data manipulation language (OODML). Once the OO query is | 
parsed by the OODML compiler, it is transformed into the equivalent ABDL queries and a 
series of pseudocode in compliance with the protocol between the OODML compiler and 
the RTM. The RTM executes the operations specified by the pseudocode by using its built- 
in functions. However, for the execution of the ABDL queries, it communicates with the 


Kernel DBMS. 
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I. INTRODUCTION 


Different Database Management Systems (DBMS) are derived from different data 
models and data languages. These DBMS create heterogeneous databases. To increase the 
effective utilization of all these data stored in various databases and to prevent the data 
duplication of one database into the other database, the researcher begins to search a way 
for the interoperability of heterogeneous databases and their DBMS. | 

Although it is still in experimental phase, the interoperable solution developed at 
the Laboratory for Database System Research in the Naval Postgraduate School may turn 
out to be the most promising one, since it removes the limitations of the other solutions 
offered so far. For a detailed explanation of the other solutions and their limitations, the 


reader is to refer to [Ref. 1]. Our interoperable solution is the Multimodel, Multilingual and 


Multibackend Database System (M°DBMS) with the Cross-Model-Accessing Capabilities 


(CMAC), where all the heterogeneous databases are integrated into a kernel database. This 


integration is done automatically by the M°DBMS with the CMAC and is transparent to the 
user. More specifically, the system enables the user to create a database in the data model 
preferred, to:-access and manipulate not only the user’s own database but also the other 
users’ databases. For example, based on the other data models, the relational user of a - 
relational database may access a hierarchial database as if it is a relational database. The 
multimodel, multilingual and CMAC characteristics ensure the interoperability of 
heterogeneous databases; the multibackend characteristic ensures the parallel operations 
and huge storage of the databases. In this system there is an interface for each distinct pair 
of data model and data language. For the database creation, the interface converts a 
database created in a specific data model into the kernel (1.e., attribute-based) data model 
format and creates for it the kernel database organized as attribute-value pairs. For the 
manipulation of the database, the interface also converts the queries in the user’s favorite 
data language into the kernel (1.e., attribute-based) data language (ABDL). The entire 


system is depicted in Figure 1. 
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Figure 1: Interfaces, Databases and Schemas in ean with CMAC 








Beginning in the early 90’s the Object-Oriented Database Management Systems 
(OODBMS) became one of the major trends in the database world. Many “next- 
generation” applications, such as computer-aided design and manufacturing systems, 
computer-aided software engineering, multimedia and hypermedia information systems, 
and artificial intelligence expert systems require databases that can support objects of a 
variety of types with ability to express complex relationships among objects [Ref. 2]. Since 
conventional database systems (network, hierarchial and relational models) are often 
inadequate to support the requirements of these applications, OODBMS have gained more 
and more popularity. Although some vendors are enriching RDBMS and claiming that 
RDBMS are as powerful as OODBMS, there is no doubt that the latter with rich and 


complex semantic database constructs are superior to all the previous DBMS. 


Before the present thesis work, M°DBMS has supported attribute-based, 
hierarchial, network, relational, and functional data models and their corresponding data 
languages. With the completion of this and other theses, the newly emerging data model 
and data language, namely, the object-oriented data model and the object-oriented data 


language, are incorporated as an object-oriented data model/language interface into the 


M°DBMS. 

The objective of this thesis research is the design and implementation of a real-time 
monitor (RTM) for object-oriented database management. It supervises the execution of 
well-formed ABDL queries being produced by the compiler of the object-oriented data 
manipulation language (OODML). It also completes other nearly-executable ABDL 
queries for execution. Finally, it presents the answer of the query to the kernel formatting 
system (KFS). Detailed explanations of the well-formed and nearly-executable ABDL 
queries are given in the following chapters. More specifically, in the remaining chapters of 
this thesis, the need for the RTM in the Object-Oriented Interface is articulated in Chapter 
IL. In Chapter II, the interactions of the RTM with the other modules of the interface and 


the kernel database are expounded. In Chapter IV, the design and the implementation of the 








RTM are detailed. The conclusion of the thesis is included in Chapter V. Following the last 
chapter, there are appendices on the pseudocode defintions, the sample trace of a query and 


the source code of the RTM. 











II. THE NEED FOR THE REAL-TIME MONITOR IN THE OBJECT- 
~  -  ORTENTED INTERFACE 


During the design phase of the object-oriented interface, one of the important issues 
is how to convert the object-oriented operations of the interface into the equivalent ABDL 
functions in the kernel. For a detailed explanation of the object-oriented operations see 
[Ref. 3]. Although simple ABDL functions, namely INSERT, DELETE, UPDATE, 
RETRIEVE and RETRIEVE COMMON are capable of supporting complex object- 
oriented operations, there is no way to produce these ABDL functions in complete and 
executable forms. Much of the information needed for the completion and execution of 
ABDL functions must be provided by previous ABDL functions and computations. Thus, 
there is the need of a real-time monitor, which oversees the execution of the previous 
ABDL functions; receives the intermediate results from these functions, and completes the 
subsequent ABDL functions for their execution in the kernel. 

Another option might be to modify the kernel in order to handle the situation 


defined above. Since the processes in the kernel are being shared by the other interfaces of 


M°DBMS and the code regarding the implementation of the kernel database management 
system is very long and complex, any modification of the kernel would be very time 
consuming and may result in unexpected problems in building up a robust kernel database 
system. The reader is to refer to [Ref. 4] and [Ref. 5] for a detailed explanation of the kernel 
database system. So, due to the risk of introducing errors into the kernel database system 
and complicating the implementation of the object-oriented interface, the use of a layer of 
software between the object-oriented interface and the kernel is a much easier and rational 
solution. 

Besides, in all the other interfaces of M°?-DBMS, the need of a real-time monitor 
(called as the kernel controller) is inevitable. In general, the kernel controller submits the 


equivalent ABDL queries to the kernel and receives the answers from the kernel. So, the 








kernel controller acts like a real-time monitor of a stand-alone DBMS, handling the 
database accesses at the run time. 

Architectually, the RTM in the object-oriented interface is similar to the kernel 
controllers in the other interfaces. However, the RTM in the object-oriented interface 
facilitates object-oriented operations, completes all the incomplete assembled ABDL 
operations, and interacts with the kernel database system on behalf of the object-oriented 
interface. 

The role of the RTM between the object-oriented interface and the kernel is 


depicted in Figure 2. 
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Figure 2. The Role of the RTM between the Interface and the Kernel 








II. THE INTERACTION WITH OTHER SOFTWARE MODULES 


Before describing the design and the implementation of the RTM, depicting the 
relationship of the RTM with the other modules of the interface and the kernel, that is, 
defining the input and the output of the RTM will make the architecture of the RTM much 
more readable and understandable. 

Basicly, the RTM communicates with three software modules. The first is the query 
constructor, the last component of the OODML compiler, which is responsible for 
preparing the input file to the RTM, namely query_f. The RTM executes the query_f line 
by line and communicates with the kernel for the execution of each ABDL query in this 
file. So, the kernel is the second software module that the RTM interacts with. Once the 
execution of the whole query file is completed, the RTM checks if it has created an output 
file that has to be displayed to the user. If it has, then it activates the kernel formatting 
system. It is the third software module to which the RTM is related.The data flow between 
the RTM and the other software modules is depicted in Figure 3. 

In the following sections, the interaction of the RTM with the other software 


modules is expounded. 


A. THE INTERACTION WITH THE OODML COMPILER 


The input file that the RTM processes on, is prepared by the OODML compiler. 
This file consists of the translation of an object-oriented query into the attribute-based 
queries. The translation process in the OODML compiler takes seveeal steps. First, each 
object-oriented query is tokenized using the tool LEX. Once all the tokens have been 
identified, the tool YACC is used as a parser in order to check the syntactic and semantic 
correctness of the query. The parser also constructs the intermediate-language table and the 
symbol table. Finally, the query constructor produces the equivalent ABDL queries 
accessing the intermediate-language table, the data dictionary, and the symbol table 
[Ref.7]. Some of these ABDL queries are well-formed and some of them are nearly- 


executable. The query constructor also produces the pseudocode with respect to the type of 
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Figure 3: The Data Flow between the RTM and the Other Softwares 





the operations in the object-oriented query. Finally, all these statements, Le., well-formed 
and nearly-executable ABDL queries and the pseudocode are packed and sent to the RTM 
as a text file query_f. 

As stated above, the guery_f is composed of three types of statement; well-formed 
ABDL queries, nearly-executable ABDL queries, and the pseudocode. A well-formed 
ABDL query is the ABDL query which is complete and ready to be sent to the kernel 
database for execution. A nearly-executable ABDL query is an ABDL query which is 
complete in terms of the syntax of the ABDL but, incomplete in terms of the values of its 
arguments. In other words, the ABDL query includes a variable that has to be substituted 
with its value or values before execution. The value of the variable is determined from the 
execution of the previous ABDL queries. The presence of the nearly-executable ABDL 
queries is due to the fact that the compiler can not build all the ABDL queries in well- 
formed way. Since some ABDL queries are dependent on the results of the previous ABDL 
queries, there is no way for the compiler to know the answer of an ABDL query in advance 
in order to prepare the next query with the result of the previous one. Because the RTM is 
present in the course of the execution of the queries, the completion of the nearly- 
executable queries for their execution becomes a natural task of the RTM. 

The RTM always works on the object identifier (OJD) values received from the 
kernel database in response to the ABDL queries. Although the existence of the OIDs iS 
hidden from the user, it is the only way to keep track of objects, since for each object there 
is a unique OID assigned by the RTM. Consequently, all the computations and the 
manipulations performed by the RTM make use of the OID values. 

As outlined in [Ref. 3], the object-oriented operations are much more complex and 
may involve more primary ABDL operations. The for-loop, assignment, display are some 
of the object-oriented operations that do not have equivalent ABDL functions, since they 
are not storage and retrieval operations. So, to implement these operations and to complete 
nearly-executable ABDL queries for execution, there is a protocol between the RTM and 


the compiler, namely, pseudocodes. Each pseudocode is a unique single-character used for 


1] 











a particular operation. They are the only means to activate the corresponding functions in 
the RTM so that some of the object-oriented operations are performed without the kernel. 
The reader is to refer to Appendix A for the pseudocode definitions. 

Since the RTM can be assumed as a bridge between the object-oriented language 
interface and the kernel, the way the communication is handled is very important. The next 


section will focus on this issue. 


B. THE INTERACTION WITH THE KERNEL DATABASE SYSTEM 

One of the responsibilities of the RTM is to handle the inter-communication 
between the kernel database system and the object-oriented interface. The communication 
with the kernel is crucial because it is the only possible way to send an ABDL query to the 
kernel and get the result from the kernel. All communications are accomplished via the Test 
Interface (TI) process which is one of the six processes residing in the kernel. 

There are two main TI_ functions that the RTM utilizes for ABDL query execution. 
All other TI_ functions are called by way of these two functions. Once the RTM 
determines that an ABDL query is ready for execution, it calls the function 
TI_S$TrafUnit(dbid, trafunit) in the following form: 

TI_S$TrafUnit(ool_ptr -> oi_curr_db.cdi_dbname, request) 

The structure ool ptr -> oi_curr_db.cdi_dbname holds the database identifier 
(dbid) and the variable request holds the traffic unit (trafunit) which is the ABDL query 
itself. The dbid determines the database that the kernel is going to access. 

Following this function call the RTM calls the function TI_RTM_chk_res_left() to 
ensure that the request has been processed and the results from the kernel system have been 
received. The function T7 RTM chk_res_left() communicates with the rest of the kernel 
system and receives the message about the condition of the request. If errors exist, the 
fuction TI R$ErrorMessage() is called to get the error message. However, if no error 
occurs, the function 7/7 R$ReqRes() is called to receive the response from the other 


processes of the kernel system. The response buffer is then checked to see if this is the last 
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response. If it is the last response, the results are then loaded into the file response ee 
through the calls to the functions T]_ReqgRes_RTMoutput() and TI_print_RTMReqkes(), 
respectively [Ref. 5]. 

Depending on the type of the primary operation, the process on the response fis 
handled accordingly by the RTM. If the primary operation is a RETRIEVE then the file 
response_f is opened. All the responses are OID values. They are used by the secondary 
and/or primary operations followed. But if the primary operation is a RETRIEVE where 
the result is to be displayed to the user, namely, DISPLAY, then the content of the 
response _f is stored in the file ourput_f. In this case, the content of the response_f consists 
of attribute-value pairs, not OID values. The responses to all the other DISPLAY 
operations are also appended to the output_f. When the execution of the query f 1s 
completed, the RTM sends this file to the KFS. 


C. INTERACTION WITH THE KERNEL FORMATTING SYSTEM 


Once the execution of the query fis completed, the RTM checks if it has created 
the output _f. As mentioned in the previous section, this file is created in case the user wants 
the data retrieved from the database to be displayed on the screen. Since the data retrieved 
from the database is in the attribute-based format, the KFS reformats them in a tabular 
format and displays to the user in an object-oriented fashion. Since there might be more 
than one DISPLAY operations in an object-oriented query, the responses to each 
DISPLAY operation are separated by an asterisk (*) in the output_f by the RTM.On the 
basis of the separators, the KFS can determine whether it should to create a new table with 
new attribute names as the column headings. For a detailed explanation regarding the 


implementation of the KFS, refer to [Ref. 4]. 
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IV. DESIGN AND IMPLEMENTATION ISSUES 


A. THE OVERALL DESIGN OF THE REAL TIME MONITOR 


Once the function real_time_monitor() is activated with the query_f, the RTM takes 
the control in the object-oriented interface and begins to execute the query_f line by line. 
There are two types of operations that the RTM handles: Primary operations and secondary 
operations. Primary eperations are related to the execution of the ABDL functions. The 
operations regarding data retrieval and manipulation, 1.e., the operations that the RTM has 
to communicate with the kernel are referred to as primary operations. The operations 
_ internal to the RTM for the execution of the pseudocode are called as secondary operations. 

As stated before, all types of pseudocode are symbolized by one character and 
placed at the beginning of each line in the query_f. So, the first character of each line 
determines the action to be taken by the RTM. After the real time _monitor() is called, the 
program flow shifts to the main controller function rtm_exec(). The body of this function 
is a Switch statement. Since the lines are read character by character, once the first character 
of a line is read, it is compared with one of the characters defined in the switch statement 
and depending on whether it is a pseudocode or an ABDL query, the corresponding 
secondary operation or the primary operation is executed. There is a function for each type 
of pseudocode. The flowchart for the function rtm_exec() is demonstrated in Figure 4. As 
seen in Figure 4, the rtm_exec() is responsible for calling the functions regarding secondary 
operations. In case the first character of a line is a left bracket ({), the rtm_exec() calls the 
function query exec() that is responsible for the execution of the primary operations. 

The relationship between the secondary and primary operations are handled 
through the flags. Depending on the type of the pseudocode there might be a warning such 
as substitution, double substitution, assignment for the ABDL guery in the next line. In case 
of these warnings, the corresponding flags are set, so that in the next line, the status of these 
flags is checked first and the necessary action is taken before executing the ABDL query. 


At the end of the execution of the ABDL query the corresponding flags are reset. 
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The reader is to refer to Appendix B for the sample trace of a query. The script file 
in Appendix B consists of the original object-oriented query, the query_f produced by the 
query constructor, the steps taken by the RTM during the execution of the query_f, and the 
end-result displayed by the KFS. 

The software for the RTM is implemented in C programming language. The 
ttm_def.h and the rtm.c reside in the directory db/ 1/u/mdbs/greg/CNTRL/TI/LanglF/src!/ 


Obj/Kc. The reader is to refer to Appendix C for the source code. 


B. THE IMPLEMENTATION OF THE SECONDARY OPERATIONS 


As seen in Figure 4, each secondary operation is implemented as a function in the 
RTM. In the following lines, each one of these functions is described. 

create obj_ref(): This function is used to create object reference (obj_ref) and 
store it in the data structure defined below. The name and the number of the obj_refs are 
defined in the query f. The data structures used for this function are as follows: 

struct obj_ref 

char name[3]; 
char data[20]; 

hs 

struct obj_ref list_obj_ref[30]; 

The field name of the struct obj_ref is used to store the name of the obj_ref and the 
field data is used to store the OID value. Since there may be more than one obj_refs in the 
query_f, they are stored in the array list_obj_ref[30]. 

create obj_set(): This function has the same functionality as the create_obj_ref() 
does. The only difference is that the data field of the struct obj_set is defined as an array of 
array of characters since an object set (obj_set) may have more than one OID values. The 
‘data structures defined for this function are as follows: 


struct obj_set 
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char name[3]; 
char data[30][20]; 
}; 
struct obj_set list_obj_set[30]; 
prep_ass(): This function deals with the intermediate steps necessary for the 
assignment. First, it reads the name of the variable that the assignment will be done. This 
is either an obj_ref or an obj_set. Next, the index of this variable in the corresponding list 
is found and stored in the global variable index. Depending on whether it is an obj_ref or 
an obj_set, the flag o r ass or o_S_ass is set, correspondingly. The assignment is required 
by the primary operation RETRIEVE, and the secondary operations AND, OR, and 
GET_COMMON. It is used for assigning the OID values to the data field of the obj_tef/ 
obj_set referenced by the index. | 
prep subs(): This function handles the intermediate steps necessary for any 
substitution in an ABDL query. First, it reads the name of the variable to be substituted with 
the OID value in its data field. The substitution variable may be either an obj_ref or an 
obj_set. Next, the index of this variable in the corresponding list is found and with respect 
to the type of the variable the flag flag_subs_or or the flag flag_subs_os is set, 
correspondingly. The data structures defined for this function are as follows: 
struct obj_ref_set_info 
{ 
char name[3]; 
int index; 
I 
struct obj_ref_set_info subs_obj_var; 
prep double_subs(): This function handles the intermediate steps necessary for 
double substitution in an ABDL query. The difference between this function and the 


prep_subs() is that this one allows for two substitutions in an ABDL query but the type of 
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the substitution variables have to be obj_ref.The function reads the name of the variables 
from the query f. After locating their index in the list_obj_ref, it sets the flag 
flag_double_subst.The data structure defined for this function is as follows: 

struct obj_ref_set_info list_subs_obj_ref[2]; 

or_exec(): This function computes the union of the OID values in two distinct 
obj_sets and stores them in a new obj_ref/obj_set. After locating the index of each obj_set 
subject to the union, the function determines the type of the assignment variable depending 
on whether the flag o_r_ass or o_s_ass is set. If the type of the assignment variable is an 
obj_ref, then the first OID value of the first obj_set is assigned to the data field of the 
assignment variable and, the function terminates. If the type of the assignment variable is 
an obj_set, first, all the OID values in the first obj_set are assigned. Then, each OID value 
in the second obj_set is compared to the OID values in the first obj_set. If it does not match 
with any of them then it is added to the data field of the assignment variable. The data 
structure used for this function 1s as follows: 

struct obj_ref_set_info list_or_var[2]; 

and_exec(): This function computes the conjunction of the OID values in two 
distinct obj_sets and stores them in a new obj_ref/obj_set. The steps performed at the 
beginning are same as in the function or exec(). After the function begins to compare the 
OID values of the first obj_set to the second obj_set’s, the action taken depends on the type 
of the assignment variable. If it is an obj_ref, the first OID value that matches is stored in 
the assignment variable and, the function terminates. If the type of the assignment variable 
is an obj_set, the comparison between the obj_sets continue and all the OID values that are 
equal, are assigned in the specific obj_set. The data structure defined for this function is as 
follows: 

struct obj_ref_set_info list_and_var[2]; 

get_common(): This function determines the OID values in an obj_set, that are 
repeated for at least the number of OID values in another obj_set or in an obj_ref, and it 


assigns these OID values in a new obj_ref/obj_set. The first variable the function reads is 
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always an obj_set, and the second one may be either an obj_set or an obj_ref. After their 
index is determined, the type of the assignment variable is checked. If it is an obj_set and 
the second variable is an obj_ref, then all the OID values in the first variable are assigned 
to the data field of the assignment variable. If the second variable is an obj_set, then the 
OID values in the first obj_set, that are repeated for at least the number of OID values in 
the second obj_set, are assigned to the data field of the assignment variable. If the type of 
the assignment variable is an obj_ref, the same algorithm is applied again. In this case, if 
the second variable is an obj_ref, the first OID value in the first obj_set is stored in the data 
field of the assignment variable. If the second variable is an obj_set then the first OID value 
which satisfies the above criteria is assigned to the assignment variable. 

loop_exec(): This function is used for executing the statements inside a for-loop as 
the number of OID values in an obj_set. The first variable the function reads is referred to 
as index variable, and its type is always an obj_ref. The second variable the function reads 
is always an obj_set on which the number of iterations for the for-loop are computed. The 
function opens a new file, Joop_f and the statements between the beginning and the end of 
the for-loop are copied from the query f to the loop_f. Following this step, a loop is 
entered. In each iteration of this loop, the data field of the index variable 1s updated with an 
OID value of the obj_set. Since the number of iterations are equal to the number of OID 
values in the obj_set, in each iteration a new OID value is stored in the data field of the 
index variable. So, the number of the iteration determines which OID value will be copied 
from the obj_set to the index variable.In each iteration, the function rtm_exec() 1s called 


recursively. This time, the rtm _exec() receives the loop_f as its input file. 


C. THE IMPLEMENTATION OF THE PRIMARY OPERATIONS 

The RTM performs four types of primary operations, namely, RETRIEVE, 
DISPLAY, UPDATE and ADD. Once the function guery_exec() is called, it reads the next 
character in the line and branches to the corresponding function which handles a specific 


primary operation. Figure 5, depicts the flowchart for the query_exec(). 
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* The output file is generated only if display_exec is activated. 
Figure 5: The Flowchart for the query_exec() 
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In the rest of this section, each one of these functions will be described. 

retrieve _exec(): This function is used for retrieving data from the kernel database. 
First, the function prepares the ABDL query to be sent to the kernel. For this purpose, the 
ABDL query which is read from the query_f is stored in an array of characters, aumsed 
request. Next, the function checks the status of the flags flag_subs_os and flag_subs_or to 
see if the ABDL query is in well-executable or nearly-executable form. If none of the flags 
“are set, then it means that the query is in well-executable form, and sent to the kernel 
directly for execution. If the type of the substitution variable is an obj_ref, the ABDL query 
is modified substituting the variable with its OID value and sent to the kernel. If the type 
of the substitution variable is an obj_set, then for each OID value in the data field of this 
obj_set, the ABDL query is modified substituting the variable with the OID value in turn, 
and sent to the kernel. The responses received from the kernel is stored in the data field of 
the assignment variable. In case that the type of the assignment variable is an obj_ref, only 
the first OID value in the file response_f is stored in the assignment variable since its data 
field is restricted to holding just one OID value. At the end of the function, the substitution 
and the assignment flags that are found to be set at the beginning, are reset. This function 
utilizes the ABDL function RETRIEVE. The data retrieved using the function 
retrieve_exec() is always OID values. For retrieving the actual data to be seen by the user, 
‘the function display _exec() is used. 

display_exec(): This function is used for the retrieval of the data to be displayed to 
the user. In general, the function follows the same steps taken in the function 
retrieve_exec(). One difference is that the data retrieved is not assigned to a variable but 
stored in the file, output _f opened by this function. When the function 1s activated, it also 
sets the global flag flag display. So, when the execution of the guery_f is complete, the 
main program checks the status of this flag and activates the KFS if it is set. Since there 
may be more than one DISPLAY operation in the query_f, and the KFS is activated after 
the execution of the whole query_f, all the responses received from the kernel are appended 


in the output f. So, the function display_exec() writes an asterisk (*) in the output_f to 
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separate the responses to different DISPLAY operations. This function also utilizes the 
ABDL function RETRIEVE. 

update_exec(): This function is used to update the data in the kernel database. The 
steps necessary for the preparation and the transmission of the ABDL query are as in the 
function retrieve_exec(). The function makes use of the ABDL function UPDATE. 

add_exec(): This function is used for building a new relationship between the 
existing objects in the kernel database. For example, regarding the faculty-student database 
introduced in [Ref. 8], adding a student to a specific team that he was not a member of 
before, requires the use of this function. In this situation, that specific student and that 
specific team already exist in the database but they are not associated. So, the OID value of 
that student and the OID value of that team are added as a tuple in the table Student_team 
which keeps track of the students belonging to a team. To distinguish this tuple from the 
other tuples in the table, the RTM generates an OID value and associates it with this tuple. 
As stated in [Ref. 9], the tables that implement the set-of and the covering relationships are 
generated by the compiler of the object-oriented data definition language and they are 
hidden from the user. So, the function add_exec() manipulates these kind of tables. Let’s 
assume that the rtm_exec() reads the statement below from the query f , and calls the 
function query _exec() which calls the function add_exec() eventually: 

[| AINSERT(<TEMP,Student_team>,<OID,?>,<oid_student,s>,<oid_team,t>)] 

As seen above, the statements using this function are always incomplete ABDL 
queries and require an OID value and double substitution before being sent to the kernel. 
The function reads the query until it meets with the question mark (?). At this point, the 
function get objectid() is called and the OID value generated by this function is replaced 
with this character. The function get_objectid() gets the time of the day from the computer, 
parses it into an 8 digit number, and converts this number into a character string. That's 
why, each OID value is guaranteed to be unique. Then, the function add_exec() continues 


reading the query and locates the two obj_refs to be substituted with their OID values. Once 
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the substitutions are done, the query is ready for execution and sent to the kernel. This 


function utilizes the ABDL function INSERT. 
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V. CONCLUSIONS 


The goal of this thesis research is to design and implement a RTM which would 
complete and execute the ABDL queries, access the database via the kernel system at run 
time, and prepare the results to be displayed to the user. 

I successfully accomplished the task of building a RTM which would perform the 
functionality described above. The RTM is capable of executing all the object-oriented 
operations processed by the OODML compiler. The limitations of the RTM and the 


recommendations for the future research will be detailed in the following sections. 


A. LIMITATIONS 

As stated before, the RTM is not a stand-alone software. It is a layer of software 
linking the object-oriented interface to the kernel system. It is designed to work only for 
these two software. The structure of the input to the RTM is predefined by way of the 
pseudocode and the format of the responses coming back from the kernel are known in 
advance. So, any change in the input to the RTM may hinder its functionality. 

The protocol between the RTM and the OODML compiler is very strict and 
inflexible. The current protocol is sufficient for the object-oriented operations implemented 
so far. The implementation of the new object-oriented operations may require the 
generation of new pseudocode. 

The RTM does not check the syntactic correctness of an ABDL query received in 
the query_f. Since the ABDL queries are generated by the OODML compiler itself without 


user interference, the RTM assumes that they are free of errors. 


B. FUTURE RESEARCH 

Some of the object-oriented operations stated in [Ref. 3] are not implemented yet. 
These operations are insert, delete, read-input and the statistical operations, i.e., count, min, 
max, avg. Regarding the implementation of the statistical operations, there may not be any 


dependency on the OODML compiler since these operations are simple computations that 
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may be performed by the RTM itself. On the other side, for the implementation of the other 
operations, the input that the OODML compiler will provide, is a remarkable factor. For 
example, the type and the number of the substitutions in the operations insert and delete are 
to be determined by the OODML compiler. Unless these issues are fixed, the 
implementation of these operations may be very fuzzy and time-consuming. 

Another feature which has to be added to the RTM in the future is, handling the 
conditional statements in an object-oriented query. However, before the implementation of 
this operation in the RTM, the OODML compiler has to be modified to accept this kind of 
statements and the pseudocode regarding this operation has to be defined. 

Although the RTM implemented in this thesis research is built specifically for the 


object-oriented interface, it may set a good example for the new interfaces to be added to 


the M°DBMS in the future. 
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APPENDIX A- THE DEFINITIONS FOR THE PSEUDOCODE 


% : Declaration of Object Reference 

This pseudocode is used for the declaration of an object reference (obj_ref). The 
character string following the ’%’ specifies the label of the obj_ref. More than one 
obj_refs can be declared on the same line, each being separated by comma. The label of an 
obj_ref is limited to three characters. An obj_ref that is not declared, can not be used in the 


query_f. 


Example: 
%ra,rb,1,S,t 


@: Declaration of Object Set 

This pseudocode is used for the declaration of an object set (obj_set). The issues stated 
above regarding the declaration of an obj_ref are also valid for the declaration of an 
obj_ set. 


Example: 
@sa,sb,sc,sd,e 


& : Assignment Warning 
This pseudocode is used for assignment. It means that the OID values retrieved from 
the kernel database are to be assigned in the data field of the obj_ref/obj_set following the 


[RETRIEVE ((TEMP=Name)and(LNAME=wu) (OID) 


~ : Substitution Warning 

This pseudocode is used for single substitution in an ABDL query. First, the obj_ref/ 
obj_set subject to substitution is found in the ABDL query and then, replaced with its OID 
value(s). There is only one obj_ref/obj_set following the ’~’. 


Example: 


~sb 


[RETRIEVE((TEMP=Course)and(INSTRUCTOR=sb)) (OID)] 


#: Double Substitution Warning 
This pseudocode is used for double substitution in an . ABDL query. There are two 

arguments following the ’#’, each separated by comma, and the type of both arguments 1s 
obj_ref. First, the two obj_ refs subject to substitution are located in the ABDL query and 
then, replaced with their OID values. This kind of substitution occurs only in the ADD 
operation. 

Example: 

#5,t 

[AINSERT(<TEMP,Student_team>,<OID,?>,<oid_student,s>,<oid_team,t>)] 


+: Union 
This pseudocode is used to compute the disjunction of the OID values stored in two 
obj_sets. 


Example: 
SSC 
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+sa,sb 
* : Intersection : 

This pseudocode is used to compute the conjunction of the OID values stored in two 
obj_sets. 

Example: 

&sd 

*sa,Sb 


A ; Get Common 

This pseudocode is used to determine the OID values in the first argument which are 
repeated for at least the number of OID values in the second argument. The type of the 
first argument is an obj_set. The type of the second argument may be either an obj_set or 
an obj_ref. ; 


Example: 


$ : For-Loop 

This pseudocode is used for executing the statements inside a for-loop for the number 
of OID values in the second argument following the ’#’. it also marks the beginning of the 
for-loop. The first argument following the ’$’ is called as index variable of the for-loop. 
The type of the first argument is obj_ref, and the type of the second argument is obj_ set. 
He example regarding the use of this pseudocode is given following the definition of the 


! : End of for-loop 
This pseudocode marks the end of the for-loop. 


Example: 
$1,€ 


~] 
[ORETRIEVE((TEMP=Course)and(OID=i))(CNAME,CSE_NO)BY CNAME] 
| 
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APPENDIX B- THE SAMPLE TRACE OF A QUERY 


Script started on Tue Jul 11 12:51:10 1995 


[fF EEEEEEEREEERAEEAE REE EAE RCSPUOOLLEG 1 TS FEA Eee AAA ERE AREER ES 7] 


Query Display Course IS 
obj_set a; 
obj_ref 1; 
Begin 
a := find _many Course where instructor.pname.lname = 'Wu'; 
For Each 1 IN a 
display(i.cname, 1.cse_no) ; 
End_Loop; 
End; 


pseudocode for real-time monitor 

$1 

@a,sa,sb,sce 

&Sa 

[RETRIEVE ( (TEMP=Name) and (LNAME=wu) ) (OID) ] 

&sb 

~sa 

[RETRIEVE ( (TEMP=Person) and (PNAME=sa) ) (OID) ] 

&a 

~sb 

[RETRIEVE ( (TEMP=Course) and(INSTRUCTOR=sb) ) (OID) J 
Si,a 

~i 

[ORETRIEVE ( (TEMP=Course) and (OID=i) ) (CNAME, CSE_NO) BY CNAME] 


query _f 


Successfully parsed!! 


real_time_monitor() activated 
rtm_exec() activated 
create_obj_ref() activated 
create_obj_ref() terminated 
create_obj_set() activated 
create_obj_set() terminated 
prep_ass() activated 
prep_ass() terminated 
query_exec() activated 
retrieve_exec() activated 
Request= [RETRIEVE ( (TEMP=Name) and (LNAME=ww) ) (OID) ] 
(<OID, N7>) 
retrieve_exec({) terminated 
query_exec() terminated 
prep_ass() activated 
prep_ass() terminated 
prep_subs() activated 
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prep_subs() terminated 

query_exec() activated 

retrieve_exec() activated 

Request= [RETRIEVE( (TEMP=Person) and(PNAME=sa) ) (OID) ] 

mod_req = [RETRIEVE ( (TEMP=Person) and (PNAME=N7) ) (OID) ] 
{<OID, P7>) 

retrieve_exec({) terminated 

query_exec() terminated 

prep_ass() activated 

prep_ass() terminated 

prep_subs() activated 

prep_subs() terminated 

query_exec() activated 

retrieve_exec() activated 

Request= [RETRIEVE( (TEMP=Course) and (INSTRUCTOR=sb) ) (OID) ] 

mod_req = [RETRIEVE ( (TEMP=Course) and (INSTRUCTOR=P7) ) (OID) ] 
(<OID, C2>) 

retrieve _exec() terminated 

query_exec() terminated 

loop_exec() activated 

rtm_exec() activated 

prep_subs() activated 

prep_subs() terminated 

query_exec() activated 

display_exec() activated 

Request= [RETRIEVE ( (TEMP=Course) and(OID= i)) (CNAME, CSE _NO)BY CNAME] 

mod_req =[RETRIEVE( (TEMP=Course) and (OID=C2) ) (CNAME, CSE _NO)BY CNAME] 
(<CNAME, ooprog>, <CSE_NO, 4114>) 

display_exec() terminated 

query_exec() terminated 

rtm_exec() terminated 

loop_exec() terminated 

rtm_exec() terminated 

The Result of your Query is 


CNAME | CSE_NO | The end-result displayed to 
Soa i ends ter alse Neat ce aera acs en ase the user. (The steps taken 
coprog | 4114 | by the RTM are not displayed, 
normally.) 
real time_monitor() terminated 


script done on Tue Jul 11 12:54:56 1995 
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APPENDIX C- SOURCE CODE FOR THE RTM 


/* rtm.def .h*/ 
/* This file includes the structure definitions and the function declarations/ 


/* Structure holding info about an object reference */ 
struct obj_ref { . 
char name[3]; 
char data[20]; 
}; 
/* Structure holding info about an object set */ 
struct obj_set { 
' char name[3]; 
char data[30][20]; 
13 


/* Structure holding info about the location of an obj_ref/obj_set*/ 
struct obj_ref_set_info { 
char name[3]; 
int index; 
}; 
void realtime monitor (); 
void rtm_exec(); 
void create_obj_ref(); 
void create_obj_set(); 
Sold BES adeOs 
void loop_exec(); 
void prep_subs(); 
void or_exec{); 
void and_exec({); 
void get_common(); 
void prep_double_subs(); 
void query_exec({); 
void retrieve_exec(); 
void display_exec(); 


void add_exec(); 


void update_exec(); 
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/* rtm.c coded by Erhan SENOCAK (July 95) */ 


#include <stdio.h> 
#include "“rtm_def.h" 
#include <licommdata.h> 
#include <ool.h> 
#include "object_ID-h" 


#define FALSE 0 
#define TRUE i 


Struct obj_ref list_obj_ref[30]; 

struct obj_set list_obj_set[30]; 

“struct obj_ref_set_info subs_obj_var; 

struct obj_ref_set_info list_subs_obj_ref[2]; 


FILE* fp; 
FILE* outfptr; 


char c, prev_disp_req[100]; 


int o_r_ass = FALSE; 

int o_s_ass FALSE; 

int flag display; 

int same; 

int index ; 

int flag_subs_os = FALSE; 

int flag_subs_or = FALSE; 

int flag_double_subst = FALSE; 


void 
real_time_monitor {fname} 
char* fname; 


{ 
7? printf (*\nreal_time_monitor() activated"); */ 


flag_display = FALSE; 
same = FALSE; 
rtm_exec({ fname) ; 

/* Tf the flag is set this means that there is an output to be displayed to 
the user.In this case the Kfs is activated, and after the Kfs is called 
the output_f is removed */ 
if (flag_display.) { 

fclose(outfptr) ; 
system(*/u/mdbs/greg/CNTRL/TI/LangIF/src/Obj/Kfs/a.out"}; 
system("rm /u/mdbs/greg/CNTRL/TI/LangIF/src/Obj/Kfs/output_f"); 


i= printf("\nreal_time_monitor() terminated"); */ 
} 


void 

rtm_exec( fname} 

/* Main function. It opens the query file prepared by the query constructor and 
begins to read each line of the file character by character and takes the 
appropriate action by comparing the first character of each line with one of 
the characters defined below in the switch expression. */ 


char* fname; 


{ 
FILE *fopen(); 
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i printf("\nrtm_exec() activated"); */ 


fp=fopen(fname, "r"); 


while ((c = getc(fp)) != EOF) { 

switch (c) { 

case '%' : create_obj_ref(); 
break; 

case '@' : create_obj_set(); 
break; 

case '&' : prep_ass(); 
break; 

case 'S' : loop_exec({); 
break; 

case '~' : prep _subs(); 
break; 

case '+' : or_exec(); 
break; 

case '*' : and_exec(); 
break; 

case '“' : get_common(); 
break; 

case '#' : prep _double_subs(); 
break; 

case '{' : query_exec(); 

} 


} 
fclose(fp}; 


/* printf("*\nrtm_exec() terminated\n"); */ 
} 


void 

create_obj_ref () 

/* Reads each obj_ref separated by comma and stores in the 
list_obj_ref array. */ 


ant <i; 3 

i printf("\ncreate_obj_ref{) activated’); */ 
j=0; 
for (i=0 ; i1<30 ; i++) { 


strcpy(list_obj_ref[i].name, *"); 
strepy(list_obj_ref[i].data, ""); 


while {{c = getc(fp)) t= '\n') { 
1° «0 
list_obj_ref[j].name[i++] = c; 
while (( c = getc(fp)) != ‘,") { 
Le ve ee Oa) 
break; 
Drintt(“\ntsec" "cH", c)# 
list_obj_ref[j]-namef{i++] = c; 
} 
list_obj_ref[j]-name[i} = '\0O'; 
ets 
er oe ea AS 
break; 
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/* printf(*\ncreate_obj_ref() terminated"); */ 


} 


void 
create_obj_set() 
/* Reads each obj_set separated by comma and stores in the 


list_obj_set array. */ 
Ine. 442 
es printf("\ncreate_obj_set() activated"); */ 


for (i=0 ; i<30 ; i++) { 
strcepy(list_obj_set{i].name, ""); 
for (j=0 ; j<30 ; J++) 
strepy(list_obj_set[i].data[j], ""); 
} 
j=0; 
while ((c = getc(fp)) != '\n') { 
i= 0; 
list_obj_set[j].name[i++] = c; 
while ({ c = getc(fp)) != ',') { 
i a a es a ee 
break; 
list_obj_set[j].name[i++] = c; 
} 
list_obj_set[j}]-name[i] = '\0'; 


147 
T—£ ( ¢c == ‘\n') 


break; 


/* printf("\ncreate_obj_set() terminated"); */ 
i 


void 

prep_ass({)} : 

/* This function deals with the intermediate steps necessary for the 
assignment. First, it reads the name of the variable that the assignment will 
be done. Next, the index of this variable in the corresponding list is located 
and stored in the global variable index. */ 


char ass_var[3]; /* Variable .to hold obj_ref/obj_set */ 
inti = O; 


/* printf("\nprep_ass() activated"); */ 


while ((c = getc(fp)) != ‘\n') 
ass_var[it++] = ¢; 
ass_var[i] = '\0'; 
for (i=0 ; i<30 ; i++) { 
if (!(stremp(list_obj_ref[i].name, ass_var)))} { 


index = i; 
o_r_ass = TRUE; 


} 
if (o_r_ass) 
break; 
} 
if (!(o_r_ass)) { 
for. (isO: =. 2630) 7 dae) 4 
if (!(stremp(list_obj_set[i].name, ass_var))) { 
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index = ics 
o_s_ass = TRUE; 
} 
if (o_s_ass) 
break; 


/* printf("\nprep_ass() terminated"); */ 


) 


void 
prep_subs() 
-/* This function handles the intermediate steps necessary for any substitution 

in an ABDL query. First, it reads the name of the variable to be substituted 
with the OID value in its data field. The substitution variable may be either 
an obj_ref or an obj_set. Next, the index of this variable in the corresponding 
list is found and with respect to the type of the variable the flag_subs_or or 
the flag_subs_os is set.*/ 


Tit 4a=U;. “5 
"ee printf("\nprep_subs() activated"); */ 


while {(c = getc(fp)) ‘t= '\n') 
subs_obj_var-name[i++] = c; 
subs_obj_var.name[i] = '\0'; 
for (j=0 ; 3<30 ; j++) { 
if (!(stremp(list_obj_set[j].name, subs_obj_var.name))) { 
subs_obj_var.index = }; 
fiag_subs_os = TRUE; 


} 
if ({flag_subs_os) 
break; 
} 
for (j=0 ; 3«<30 ; j++) { 
if (!(stremp(list_obj_ref[j].name, subs_obj_var.name))) { 
subs_obj_var.index = j; 
flag _subs_or = TRUE; 
} 
if (flag _subs_or) 
break; 
} 
/* printf("*\nprep_subs() terminated"); */ 
} 
void 


prep_double_subs({) 

/* This function implemented for the need of add_exec() function.Due to the 
characteristic of add operation two substitutions have to be made inside 
the INSERT ABDL request. Beware that this function is not used for any other 
purpose. So, the value of the flag_double_subst is checked only in the 
add_exec() function. */ 


int Tig 120 
pe printf("\nprep_double_subst() activated"); */ 


for ( iz0; i<2 ; i++) { 
strepy (list_subs_obj_ref[i]-.-name, ""); /* The list _subs_obj_ref is 
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list_subs_obj_ref[i].index = 31; cleaned from the previous values */ 
} 
while ((ce°= gete(fip)) f= "An"? 4 

i=0; 

list_subs_obj_ref[j].name[i++] = c; 

while (le °= gete( ip) ). ast") <4 

Lf (esses -*\n") 
break; 


list_subs_obj_ref[}].name[i++] = c; 
} 


list_subs_obj_ref[j]-name[i] = '\0'; 
j++; 
he iC ONE) 

break; 


/* The index of the obj_refs' read above are found searching thru list_obj_ref 
and stored in the list_subs_obj_ref. */ 

for (j=0 ; j<2 3; j++) { 
for (i=0; i<30 ; i++) { 


if (!(stremp(list_obj_ref[i].name , list_subs_obj_ref[j].name))}) { 
list_subs_obj_ref[j].index = i; 
break; 
} 
} 
} 
/* Check if the indexes were found and if found assign the flag TRUE */ 
if ((list_subs_obj_ref[(0].index != 31) && (list_subs_obj_ref[1]-.index != 31)) 


flag _double_subst = TRUE; 


/* printf("\nprep_double_subst{) terminated"); */ 
} 


void 


or_exec() 
/* This function computes the union of the OID values in two distinct obj_sets 


and stores them in the obj_ref/obj_set referred by the function prep_ass(). */ 


struct obj_ref_set_info list_or_var[2]; 
int i, j=0, n,col=0, k,l, found, not_exist, id, done=FALSE; 


printf("\nor_exec() activated"); 


/* Obj_sets to be worked on are put in an array */ 


while ((c = getc(fp)) != '\n') { 
i=0; 
list_or_var[j]-.-name[i++] = c; 
wiile ((c = getetip)): t= °,"*}) 4 
is. use - Vn) 
break; 
list_or_var[{j].name[i++] = c; 
} 
list_or_var[j]-name[i] = ‘\0'; 
j++; 
ey ee eee SAT) 
break; 


} 
/* The index of the obj_sets read above are found in the list_obj_set */ 
for {j=0 ; j<2; JF++) { 
found = FALSE; 
for (i=0; i<30 ; i++) { 
if (!(stremp(list_obj_set[i].name , list_or_var[j].name))) { 
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/* 


i) 





list_or_var[j].index = i; 
found = TRUE; 

} 

if (found) 
break; 


} 
1=0; 
id = list_or_var([(0].index; 
If the type of the assignment variable is an obj_set, first, all the OID values 
in the first obj_set are assigned to the assignment variable. Then, each OID value 
in the second obj_set is compared to the OID values in the assignment variable. If it 
does not match with any of them then it is assigned to the assignment variable too. */ 
if (o_s_ass) { 
while (list_obj_set[id].data[i][col]) { 
strcpy(list_obj_set{index}-.data[i], list_obj_set[id] .data[i]); 
i++; 
} 
j=0; 
k=0; 
while (list_obj_set[list_or_var[1].index].data[j][col]) { 
not_exist = TRUE; 
for (nm=0 ; n<i ; n++) { 
if (!(stremp(list_obj_set [index] .data[n], 
list_obj_set[list_or_var[1]-.index] -data[j]))) 
not_exist = FALSE; 
} 
if (not_exist) { 
1s i+k; ; 
strepy(list_obj_set[index].data[1l], list_obj_set[list_or_var[1] .index] .data[j]); 
k++; 
} 
a 
} 
o_s_ass = FALSE; 
index = 31; /* index can hold a value between 0-29 since the size of the arrays 
is 30. Assignment of 31 is a second safety measure else than 
the flags o_r_ass and o_s_ass.*/ 
} /* End of if (o_s_ass) */ 
If the type of the assignment variable is an obj_ref, then the first OID value 
of the first obj_set is assigned. If there is no OID value in the first obj_set 
then the first OID value in the second obj_set is assigned and the function 
terminates */ 
else if (o_r_ass) { 
if (list_obj_set[id].data[{i][col]) { 
strepy(list_obj_ref[index].data, list_obj_set[id].data[i]); 
cone -= TRUE; 
} 
if (!(done)) { 
k=0; 
if (list_obj_set[list_or_var[1].index].data[0][col]) { 
strcpy (list_obj_ref[index].data, list_obj_set[list_or_var[1].index].data[0]); 
} 
} 
o_r_ass = FALSE; 
index = 31; 
} /* End of if (o_r_ass) */ 


printf ("\nor_exec() terminated") ; 
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void 

and_exec() 

/* This function computes the conjunction of the OID values in two distinct 
obj_sets and stores them in the obj_ref/obj_set referred by the function 


prep_ass() */ 


struct obj_ref_set_info list_and_var[2]; 
int i, j=0, n,col=0, k=0, found; 


/* printf(*\nand_exec() activated"); */ 
td 


/* Obj_sets to be worked on are put in an array */ 


white: -((cagetctip)) t=: "\n"). 4 
i=0; 
list_and_var[j].name[it++] = c; 
while ((c = getc(fp)) != ',')f{ 
Le 4 e-em) 
break; 
list_and_var[j].name[i++] = c; 
} 
list_and_var[j].name[i] = '\0°'; 
jtt+; | 
nip Gam Ge Om A 0 a 
break; 


} 


/* The index of the obj_sets read above are found in the list_obj_set */ 
for {j=0 ; j<2 ; j++) { 
found = FALSE; 
for (i=0; i<30 ; i++) { 
if (!(stremp(list_obj_set[i].name, list_and_var[j].name))) { 
list and var[}).index = i; 
found = TRUE; 
} 
if (found) 
break; 
} 
} 


/* The data values in each obj_set are compared with eachother and the values 
that match are assigned to the object set specified by the prep_ass() */ 
i1=0; 
if (o_s_ass) { : 

while (list_obj_set[list_and_var[0].index].data[i][col]) { 
j=0; 
found = FALSE; 
while (list_obj_set[list_and_var[1].index].data[j][col]) { 
if (!(stremp(list_obj_set[list_and_var[0]-.index].data[il], 
list_obj_set[list_and_var[1]-.index].data[j]))) { 
strepy (list_obj_set [index].data[k], 
list_obj_set[list_and_var[0].index].data[i]); 
k+4+; 
found = TRUE; 
} 
1£ (found) 
break; 
+47 
} 
++1;7 
} /* End for while */ 
o_s_ass = FALSE; 
index = 31; 
} /* End for if (o_s_ass) */ 
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if (o_r_ass) { | 
while (list_obj_set[{list_and_var[0].index].data[i][col]) { 
j=0; 
found = FALSE; 
while (list_obj_set[list_and_var[1].index].data[j][col]) { 
if (!(stremp(list_obj_set[list_and_var[0].index].data[i], 
list_obj_set[list_and_var[1].index].data[j]})) { 
strcepy(list_obj_ref [index] .data, 
list_obj_set[list_and_var[0].index] .data[i]); 
K++; 
found = TRUE; 
} 
if (found) 
break; 
++); 
} 
if (found) 
break; /* Obj_ref assignment */ 
++i; 
} /* End for while */ 
O_r_ass = FALSE; 
index = 31; 
J /* End for if (o_r_ass) */ 


J* printf ("\nand_exec() terminated"); */ 


} 


void 
loop_exec({) 
/* This function is used for executing the statements inside a for-loop as the 
number of OID values in an obj_set. */ : 
{ 
int i= 0, refindex, setindex, j = 0; 
char refname(3], setname[3]; 
FILE* fpointer; 


f* printf("\nloop_exec{) activated "}); */ 


/* The first variable read is the index of the for-loop. */ 


while (( c = getc(fp)) != ',') 
refname[it++] = ¢c; 

refname[i] = '\0'; 

i= 0; 

while {( c = getc(fp)) t= '\n') 
setname[i++] = c; 

setname[i] = '\0O'; 


/* The statements between the beginning and the end of the for-loop are written 

in the file loop_f. */ 

fpointer = fopen("loop_f", "w"); 

while (( c = getc(fp)) t= '!') 

putc(c, fpointer); 

fclose(fpointer) ; 

& =.getctfp}-; 

for (i=0 ; i1<30 ; i++) { 


if (!(stremp(list_obj_ref[i].name, refname))) { 
refindex = i; 
break; 
} 
} 
for (i=0; i<30 ;i++) { 
if (!(strcemp(list_obj_set[i].name, setname))) { 
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setindex = lI; 
break; 


} 
1 = O; 
(pointer: .=fp: 

/* Loop is entered. The number of iterations are computed with respect to the 
number of OID values in the obj_set. In each iteration the rtm_exec({) 1s 
called recursively. */ 

while (list_obj_set[setindex].data[il{j]}) { 
strcpy(list_obj_ref[refindex].data, list_obj_set[setindex] .datal[i]); 
rtm_exec("*loop_f"); 


L++; 
} 
fp = fpointer; 
/* printf("loop_exec() terminated"); */ 
} 
void 


get_common ( ) 
/* This function determines the OID values in an obj_set, that are repeated for 


at least the number of OID values in another obj_set or in an obj_ref and 
assigns these OID values in an obj_ref/obj_set located by the function 


prep_ass() */ 


{ 
int i=0, j=0, p=0, k=0, repeat, setsize=0, setindex, arg2size=0, arg2index; 
int done=FALSE; 
char setname[3], arg2name[3]; 
/* printf("\n get_common() activated "); */ 
while {{ c = getc(fp)) != ','") 
setname[i++] = c; 
setname[i] = '\0’°; 
see 0 oe 
while (({ c = getc(fp)) t= '\n') 
arg2name[i++] = c; 
arg2name[i] = '\0'; 
for ( i=0 ; i<30 ; i++) { 
if (!(stremp(list_obj_set[i]-name, setname))) { 


setindex = i; 
while (list_obj_set[i].data[{j++][k]) 
setsize = j; 


break; 
} 
} 
j=0; 
for ( izO ; i<30 ; i++) { , 
if (!(stremp(arg2name,list_obj_set[i].name))) { 
arg2index = 1; , 
while (list_obj_set[i].data[{j++] [k]) 
arg2size = j; 
done = TRUE; 
} 
else if (!(stremp(list_obj_ref[i].name, arg2name))) { 
if (list_obj_ref[i].data[k]) 
aYOZS1Z7e:= ks 
done = TRUE; 
} 
if (done) 
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break; 
} 
done = FALSE; 
if (o_s_ass) { 
if (arg2size == 0) 
else { 
if: (arg2size-== 1) .{ 
for ( i=0 ; i<setsize ; i++) 
strepy(list_obj_set[index].data[i], list_obj_set[setindex].data[i]); 


} 
else { 
for (i=0 ; ix<xsetsize ; i++) { 
repeat = 0; 
for (j=i ; j<setsize ; j++) { 
if (!(stremp(list_obj_set[setindex] .data[i], 
list_obj_set{setindex].data[j]))) { 
repeat++; 
if (repeat == arg2size) 
strepy(list_obj_set{index] .data[p++], 
list_obj_set{setindex].data[i]); 
} 
} 
} 
} 


} 
os ass = FALSE; 
index = 31; 


} /* End of if (o_s_ass) */ 
else if (o_r_ass) { 
af. (arg2size, ==) '0) 
else { 
if (arg2size == 1) { 


for ( i=0 ; i<setsize ; i++) { 
strcepy(list_obj_ref[index].data, list_obj_set[setindex] .data[i]); 
done = TRUE; . 
if (done) 
break; 


} 
else { 
for {i=0 ; i<setsize ; i++) { 
repeat = 0; 
for ({j=i ; j<setsize ; j++) { 
if (!(stremp(list_obj_set [setindex].data[i], 
list_obj_set[setindex]-.data[j])})) { 
repeatt++; 
if (repeat == arg2size) { 
strepy(list_obj_ref[index].data, list_obj_set[setindex}.data[i]); 
done = TRUE; 
} 
if (done) 
break; 


} 


L£ (done) 
break; 


4] 





o_r_ass = FALSE; 
index = 31; 
} /* End of else if (o_r_ass) */ 
/* printf(*\n get_common() terminated "); */ 


} 


void 

query_exec{) 

/* This function is used for branching to a function regarding a specific type of 
data manipulation and retrieval operation. */ 


{ 


has printf ("\nquery_exec() activated"); */ 


¢ = getec(fp); 
switch (c) { 


case 'R' : retrieve_exec(); 
break; 
case 'O' : display_exec(); 
break; 
case 'A' : add_exec(); 
break; 
case 'U' : update_exec(); 
break; 
} 
| as printf ("\nquery_exec() terminated"); */ 
} 
void 


retrieve_exec({) 
/* This function retrieves data, specifically, OID values from the kernel database. 


If the type of the substitution variable in the ABDL query stored in the request 
array is an obj_ref, then the ABDL query is modified substituting the variable 
with its OID value and sent to the kernel. If the type of the substitution 
variable is an obj_set then for each OID value in the data field of this obj_set, 
the ABDL query is modified substituting the variable with the OID value in turn 
and sent to the kernel for execution. If there is no substitution in that case 
the whole query is sent directly to the kernel. The responses received back are 
stored in the assignment variable. */ 


char request[{100], req_parti[100], req_part2[100], mod_req[100], temp[30], ch; 
int i=0, j=0, z=0, k, n, 1=0, t=0, s, once = 0; 
FILE *fptr, *fopen(); 

J printf("\nretrieve_exec() activated"); */ 


2 (iar 


request [i++] 


request[i++] = 'R'; 
while ((c = getc(fp)) != ‘'\n') { 

if ( c #2 EOF) 

break; 

request[i++] = c; 
} 
request[i] = '\0'; /* ABDL query read in the request */ 
i=0; 


if (flag_subs_os) { 
for {( k=0 ; k<2 ;k++) { 
while {requestfi} != ‘'=') 
req_parti[j++] = request[i++]; 
req _parti[j++] = request[i++]; /*Everything till second equality copied*/ 
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req partlij} =: "V's 
k =-0; 
while (request[i] != ')') 
temp[k++] = request [i++]; 
temp[k] = ‘'\0'; 
while (request[{i]}] != '\0') 
req_part2[z++} = request[i++]; 
req_part2[{z] = request[i]; 
if (!(stremp(temp, subs_obj_var.name))) { 
n =0; 
while ( list_obj_set[subs_obj_var.index].data[n][1]) { 
strepy( mod_req, req_partl); 
/* OID value is inserted in the ABDL query */ 
strceat( mod_req, list_obj_set [subs_obj_var.index] .data[n]); 
streat( mod_req, req _part2)}; /*whole request constructed */ 
TI_S$TrafUnit( ool_ptr -> oi_curr_db.cdi_dbname, mod_req); 
TI_chk_reqs_left(); 
fptr = fopen(*/u/mdbs/greg/CNTRL/TI/LangIF/src/Obj/Kc/response_f","r"); 


if (o_s_ass) { 


if (! (once) ) 
once = t; 
t = 0; 
t = t + once * n; 
while (( ch = getc(fptr)) != EOF) { 
white -{(“ch = getctiptr)) t=] *)%). 4 
if (ch == EOF) 
break; 


} 
1f£ (ch == EOF) 


break; 
ch = getc(fptr); /* space before OID value is skipped */ 
s = 0; . 
white -{(. ch = gete(iper)) t= -'S") 4 
if ( ch == EOF) 
break; 
list_obj_set [index] .data[t] [s++] = ch; 


} 
if (ch == EOF) 


break; 
list_obj_set [index] .data[n][s] = '\0'; 
Car? 
if ( ch == EOF) 
break; 
} 
} /* end of if */ 
else if (o_r_ass) { 
t = O; 
while ({( ch = getc(fptr)) != EOF) { 
while :( 0 [Ch gete. Eptr)). ta." 
/* blank space between ',' and OID value skipped */ 
ch = qete(fiptr):; 
while (( ch = getc(fptr)) != '>') 
list_obj_ref [index] .data[t++] = ch; 
list_obj_reffindex].data[t] = '\0'; 


Oo _r_ass = FALSE; 
index = 31; 
break; 7 /* while loop broken */ 
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n++; /* data[n] incremented */ 


fclose(fptr); 
} j* end of while */ 
if (o_s_ass) { 

o_s_ass = FALSE; 

index = 31; 


} [ Ena6f LE UV Strciips:.:. 3) Ff 


flag_subs_os = FALSE; 
subs_obj_var-.index = 31; 
} /* End of if(flag_subs_os) */ 
else if (flag_subs_or) { 
for ( k=0 ; k<2 ;k++) { 
while (request[i] != '=') 
req_parti[j++] = request[it++]; 
req parti[{j++] = request[i++]; /*Everything till second equality copied*/ 
} 
red: parth (5) = 7 N0" 3 
k = 0; 
while (request[ij != ')') 
temp[k++] = request [i++]; 
temp[k] = '\0'; 
while (request{i] != '\0') 
req_part2[z++] = request[i++]; 
req_part2[z] = request[i]; 
if (!(strcemp(temp, subs_obj_var-.name))) { 
if ( list_obj_ref[subs_obj_var.index].data[1l]) { 
strepy( mod_req, req_partl); 
streat({ mod_req, list_obj_ref[subs_obj_var. index] .data); 
streat( mod_regq, req_part2); 7 ™ whole request constructed */ 
TI_s$TrafUnit( ool_ptr -> oi_curr_db.cdi_dbname, mod_req); 
TI_chk_reqs_left(); 
FpEY = fopen(*/u/mdbs/greg/CNTRL/TI/LangiF/src/0bj/Kc/response_f","r"); 
if (o_s_ass) { 


t=0; 
while ({ ch = getc(fptr)) != EOF) { : 
while (({ ch = getc(fptr)) != ',') { 
if {ch == EOF) 
break; 
} 
if. (en. ==. BOR) 
break; 
ch. =‘geteCEptr):; /* space before OID value is skipped */ 
S = 0; 
who le- (C ich = -gete(iptr)): f= Ss"). 4 
if ( ch == EOF) 
break; 


list_obj_set[{index] .data[t][s++] = ch; 


} 
if (ch == EOF) 


break; 
list_obj_set[index].data[t][s] = '\0'; 
C++; 
if ( ch == EOF) 

break; 


} 

o_s_ ass = FALSE; 

index = 31; 
} /* end of if */ 
else if (o_r_ass) { 


A4 








t = 0; 
while (( ch = getc(fptr)) != EOF) { 
while ({ ch = getc(fptr)) != ',') 


‘ 


/* blank space between ',' and OID value skipped */ 

eh .=-gqerc(ttptr)> 

while (( ch = getc(fptr)) != '>') 
list_obj_ref [index] .data[t++] = ch; 

list_obj_ref [index] .data[t]} = '\0'; 

O_r_ass = FALSE; 

index = 31; 

break; /* while loop broken */ 


} 
fclose(fptr); 
} /* end of if */ 
} /* End of if (!(stremp....)) */ 
flag_subs_or = FALSE; 
subs_obj_var.index = 31; 
} /* End of if(flag_subs_os) */ 
else { 
Ti_ssTrafUnit( ool_ptr -> oi_curr_db.cdi_dbname, request); 
TI_chk_regqs_left({); 
fptr = fopen(*/u/mdbs/greg/CNTRL/TI/LangIF/src/Obj/Kc/response_f" , "r"); 
if (o_s_ass) { 


t= oO: 
while (( ch = getc(fptr)) != EOF) { 
while (( ch = getc(fptr)) != ',') { 
if ( ch == EOF ) 


break; 


=e 


} 
if { ch == EOF ) 


break; 
ch = getc(fptr}); /* space before OID value is skipped */ 
os = 0; 
while (( ch = getc(fptr)) != '>') { 

1f ( ch == EOF) 

break; 

list_obj_set [index] .data({t][s++] = ch; 
} 
if ( ch ==-E0oOF ) 

break; 
list_obj_set [index].data[t][s] = '\0'; 
t++; 


} 
Oo_S ass = FALSE; 
index = 31; 

} 


else if (o_r_ass) { 


tse oO 
while (( ch = getc(fptr)) != EOF) { 
while ({( ch = getc(fptr)) != ',') 
ch = getc(fptr); /* blank space between ',' and OID value skipped */ 
while (( ch = getc(fptr)) != '>')} 
list_obj_ref[{index] .data[t++] = ch; 
list_obj_ref[index].data[t}] = '\0'; 


O_Y_ass = FALSE; 
index = 31; 
break; /* while loop broken #*/ 
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} 
fclose(fptr); 


} 


Pe printf ("*\nretrieve_exec({)} terminated"); */ 


} 


void 
display_exec()} 
/* This function retrieves the data to be displayed to the user. */ 
{ 
char ch,request[{100], req_part1[100],req_part2[100], mod_req{1i00], temp[30]; 
int 120; 4=0:,: Z=0;.. “Ky. n;,- b=0; 
FILE* fopen()}; 
FILE* fptr; 


/* printf("\ndisplay_exec() activated"); */ 


request[i++] = '['; 


while ((c = getc(fp)) != ‘\n') { 
if ( c == EOF) 
break; 
request [i++] = c; 
} 
request{i] = '\0'; /* ABDL query read in the request */ 


if (!(flag_display)) { 
/* The responses are stored in the output_f */ 
outfptr = fopen("/u/mdbs/greg/CNTRL/TI/LangIF/srce/Obj/Kfs/output_f", “a"); 
flag_display = TRUE; 
strcpy (prev_disp_req, request); 
} 
/* The flag same is used to separate the responses to different DISPLAY operations 
in the same query_f. */ 
if (!(stremp(prev_disp_req, request) )) 
same = TRUE; 
else { 
strepy (prev_disp_req, request); 
same = FALSE; 
} 
=O 
if (flag_subs_os) { 
for ( k=0 ; k<2 ;k++) { 
while {request[i] != ‘=') 
req_partl[j++] = request[i++]; 


req_partl[j++] = request[i++]; /*Everything till second equality copied*/ 
} 
req partl[7]-.=: *\G"; 
Ks 
while (request[i] != ')}') 
temp([k++] = request [i++]; 
temp ik] =: "\0"s 
while (request[i] != '\0') 
req_part2[z++] = request[i++]; 
req _part2[z] = request[i]J; 
if (!(stremp(temp, subs_obj_var.name))) { 
nh =0s 


while ( lList_obj_set[subs_obj_var-.index].data[n][1]) { 
strepy( mod _req, req _partl1); 
strcat( mod_req, list_obj_set[subs_obj_var.index] .data[n}); 
strceat( mod_req, req_part2); /* whole request constucted */ 
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/* 
} 





TI_S$TrafUnit( ool_ptr -> oi_curr_db.cdi_dbname, mod_req); 
TI_chk_reqs_left(); 
if (!{(same}) 

Dutcl* **s. -OuEEDEr )¢ 


fptr = fopen("/u/mdbs/greg/CNTRL/TI/LangIF/src/Obj/Kc/response_f",*r 


— 


while (( ch = getc(fptr)} != EOF) 
pucci(ch,. -curLtptr)+ 


fclose(fptr); 
n++; /* data[n] incremented */ 


} f* end of while */ 
} /* End of if (!(stremp....}) */ 
flag_subs_os = FALSE; 
subs_obj_var.index = 31; 
} /* End of if(flag_subs_os) 
else if (flag _subs_or)} { 
for ( k=0 ; k<2 ;k++) { 
while (request[i] != 


'=!') 


aa) 


ty 


ae 


req parti[j++] = request[i++]; 
req _partl[j++] = request[i++]; /*Everything till second equality copied*/ 
} 
reg-pareil [7] -s°°\0"; 
k = 0; 
while (requestfi] != ')') 
temp[k++] = request[i++]; 
temp[k] = '\0O'; 
while {request[i] != '\0') 
req_part2[z++] = request[i++]; 
req_part2[z] = request[i]; 
if (!(strcemp(temp, subs_obj_var.name))) { 
1f ( list_obj_ref[{subs_obj_var.index].data[l]) { 
strepy( mod_req, req_partl1); 
strceat( mod_req, list_obj_ref[subs_obj_var.index] .data); 
strceat( mod_req, req_part2); /* whole request constucted */ 
TI_s$TrafUnit( ool_ptr -> oi_curr_db.cdi_dbname, mod_req) ; 
TI_chk_reqs_left(); 
if (!(same)) 
DULCI"* "OnE Tptr) : : 
fptr =fopen("/u/mdbs//greg/CNTRL/TI/LangIF/src/Obj /Kc/response_f*","r 
while (( ch = getc(fptr)) != EOF) 
pute (ch, outEper):- 
fclose(fptr); 
} /* end of if */ 
} /* Bndof: 2t (4tstremos <2). 77 


flag_subs_or = FALSE; 

subs_obj_var.index = 31; 
} J# End of if({flag_subs_or) */ 
else { 

TI_S$TrafUnit( ool ptr -> oi_curr_db.cdi_dbname, request) ; 

TI _chk_reqs_left(); 

if (!(same) ) 

pute! >*. OULEpEr)- 


fptr = fopen("/u/mdbs//greg/CNTRL/TI/LangIF/src/Obj/Kc/response_f" , "“r"); 


while (( ch = getc(fptr)) != EOF) 
pute(ch; -Outiptr): 
fclose(fptr) ; 


} /* end for else *¥/ 


printf("\ndisplay_exec() terminated"); */ 
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void 
update_exec() 
/* For updating the data in the kernel database. Similar steps as in the function 


retrieve_exec() are taken. */ 


char request[100], req_part1[100],req_part2[100], mod_req[100], temp[30]; 
ime: -ts0, 7=0,.7=0, ky at. 105 


ye printf (*\nupdate_exec() activated"); */ 


request[{i++]) = '['; 
request [i++] = ‘U'; 
while ((c = getc(fp)) != '\n') { 

i Co 2S “BOF } 

break; 

request [i++] = c; 
} 
request[i] = '\0'; /* ABDL query read in the request */ 
i=0; 


if (flag _subs_os) { 
for ( k=0 ; k<2 ;k++) { 
while (request[i] != ‘=') 
req parti[j++] = request[i++]; 
req_partl[j++] = request[i++]; /*Everything till second equality. copied */ 


} 

req_parti[j] = '\0'; 

Ke Os 

while (request[i]}] != ')') 
temp[k++] = request[i++]; 

temp[k] = '\0'; 

while (request[i} != '\0') 
req _part2[z++] = request[it++]; 

req_part2[z} = request[i]; 

if ('(stremp(temp, subs_obj_var-.name))) { 
n =0; 


while ( list_obj_set[subs_obj_var-index].data[{nJ{1]) { 
strcepy( mod_req, req_partl); 
streat( mod_reg, list_obj_set[subs_obj_var-.index].data[n]); 
streat( mod_req, req _part2); ‘as whole request constructed */ 
TI s$TrafUnit( ool_ptr -> oi_curr_db.cdi_dbname, mod_req}); 
TI_chk_reqs_left(}; 


n++; /* data[n] incremented */ 
} /* end of while */ 
} | End of if (!(stremp....)) */ 


flag_subs_os = FALSE; 
subs_obj_var.index = 31; 
} [* End of if(flag_subs_os) */ 
else if (flag_subs_or) { 
for { k=0 ; k<2 ;k++) { 
while (request[i] != ‘=' 
req_partl[j++] = request[it++]; 


req_part1l[j++] = request[i++]; /*Everything till second equality copied */ 
} 
req. parca) = )\e"- 
k = OQ; 
while (request[i] != ')') 

temp[k++] = request [i++]; 
Fempl ei. <=: *\0" 
while (request{i] t= '\0') 

req_part2{z++] = request [i++]; 


req_part2[z] = request[i]; 
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if (!(stremp(temp, subs_obj_var.name 
TE 
strepy( mod_req, 
strceat( mod_red, 


strceat( mod_req, 


req_partl); 


req_part2); 


Lae <4 


list_obj_ref[subs_obj_var.index] .data[1l}) 


/ 





{ 


list_obj_ref[{subs_obj_var.index] .data); 
* whole request constucted */ 


TI_S$TrafUnit( ool_ptr -> oi_curr_db.cdi_dbname, mod_req}; 


TI_chk_reqs_left(); 


} 
flag _subs_or FALSE; 


subs_obj_var.index 


— 


313 

} 

else { 
TI_SS$TrafUnit( ool_ptr -> oi_curr_db 
TI_chk_reqs_left(); 


} /* End for else */ 
/* printf ("\nupdate_exec() terminated"); 
} 
void 
add_exec(} 


/* Used for building a new relationship between the existing objects in the kernel 


/* 
/* 


f= 


.cdi_dbname, 


= 


end of if */ 


Bnd: of Lf 


End of if (flag_subs_or) 


request); 


database, not inserting a new object in the database. Before the query is 


sent to the kernel for execution, 
addition of an OID value.*/ 


char request[100], req_parti[100],req_p 
nt. 2=0). 920" 7. ky 220 > 20> 
[> printf(*\nadd_exec() activated"); */ 

request[i++] = '['; 
while ({c = getc(fp)) != '\n') { 

LE CC c= BOF) 

break; 

request [i++] = c; 
} 
request[{i] = '\0'; 
if ({flag_double_subst) { 

i=-0; 

while (request[{i] != '?') 


req_parti[j++] request [i++]; 


req _partl[(j] = ‘\0'; 

j=0; 

i++; 

while (request[i] != '\0'} 
req_part2[j++] = request[i++]; 

req_part2[j] = ‘\0'; 

strcepy(mod_req, req_partl); 


/* OID value is added in the place of '?!'! 


strceat(mod_req, get_objectid()); 


art2:[ 100), 


in the query. 


streat(mod_req, req_part2); 
1=7=07 
‘/* The first substitution is handled below */ 
for (k=0 ; k<5 ; k++) { 

while (mod_req[i}] != ',') 

req _partl[j++] = mod_reg[i++]; 

req _partl[j++] = mod_req[i++]; 
} 
req_partl[j] = '\0'; 
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mod_req[100}, temp[30]; 


/* ABDL query read in the request */ 


uP i 


(!(stremp....)) 


ef 


it is modified by double substitution and the 


i 


k=0; 
while (mod_req[i]}] != ‘>') 
temp[k++] = mod_req[i++]; 
temp[k] = "\O's 
while {mod_regq[i] != '\0') 
req part2[z++] = mod_req[i++]; 
réq part2(z)) = *\0"; 
for ( i=0 ; i<2 ; i++) { 
if (!{stremp(temp, list_subs_obj_ref[i].name))} { 
if (list_obj_ref{list_subs_obj_ref{i].index].data[l]) { 
strcpy(mod_req, req_partl); 
strceat(mod_req, list_obj_ref[list_subs_obj_ref[i].index] .data); 
strceat(mod_req, req_part2); 
} 
break; 
} 
} 
/* The second substitution is handled below */ 
1=4=2=0-; 
for {k=0 ; k<7 ; k++) { 
while (mod_reg[i] != ',') 
req_partli[j++] = mod_req[it+]; 
req_partl[j++] = mod_req[i+t+]; 
; 
req_partifj} = '\0'; 
k=0; 
while (mod_req[{i] != '>') 
temp [k++] = mod_req[i++]; 
temp{[k] = '\0'; 
while (mod_req[{i] != '\0') 
req_part2[z++] = mod_req[i++]; 
red: partzZ (2) =" \0"> 
for ( i=0 ; i<2 ; i++) { 
if (!(stremp(temp, list _subs_obj_ref[{i]-.name))) { 


if (list_obj_ref[list_subs_obj_ref[i].index].data[1l]) { 


strcepy(mod_req, req_parti); 
streat(mod_req, list_obj_ref[list_subs_obj_ref[i] .index] .data)j; 


strceat(mod_regq, req_part2); 
} 


break; 
} 


} 
TI _s$TrafUnit( ool_ptr -> oi_curr_db.cdi_dbname, mod_req}); 


TI_chk_reqs_left(); 
flag_double_subst = FALSE; 
}. /* End of if -*/ 


es printf ("\nadd_exec() terminated"); */ 


} 
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